Long duration transactions are transactions that keep their data modifications atomic and isolated from concurrent transactions for relatively longer periods of time. Long duration transactions are utilized in some workspace management systems that allow users to perform “off line” manipulation of data. In such systems, workspaces are used to model the long transaction semantics and multiple copies of data modified through data manipulations in a workspace environment are created to maintain a transaction-private version of the data that is reconciled with the live data version when the transaction (workspace) is completed.
The database management systems that support long transactions using version control define the unit of versioning as a row identified by a primary key and the same is used to determine conflicts among concurrent transactions. That is, when a long transaction modifies a column value, a private copy of the corresponding row, with the updated column value, is created for the transaction. The versioned row is used in the place of its ancestors (determined by the matching primary key) for all subsequent queries within the transaction. Concurrent transactions modifying the data in a same single row conflict with each other and these conflicts are reconciled before the transactions are merged/committed. Often the conflict detection is automated so that a transaction involved in a conflict is prevented from committing. Pessimistic locking mechanism may be used to prevent conflicts from happening. Existing implementations of version control systems detect physical conflicts between transactions by relying on the primary keys of modified rows in a relational database to flag conflicting data modification operations. For instance, if one transaction modifies a column value in a row with a specific primary key and another transaction modifies (any column in) the same row, these two transactions are determined to conflict on the row.